Event-driven simulation of IP using third party event-driven simulators

ABSTRACT

A method of creating a secure intellectual property (IP) representation of a circuit design for use with a software-based simulator can include translating a hardware description language representation of the circuit design into an encrypted intermediate form and compiling the intermediate form of the circuit design to produce encrypted object code. The method further can include linking the encrypted object code with a simulation kernel library thereby creating the secure IP representation of the circuit design. The secure IP can include an encrypted simulation model of the circuit design and a simulation kernel configured to execute the encrypted simulation model.

BACKGROUND

1. Field of the Invention

The embodiments disclosed herein relate to the field of integratedcircuits and, more particularly, to creating a secure softwarerepresentation of a circuit design for use in testing and/orverification with a software-based simulator.

2. Description of the Related Art

Modern integrated circuits (ICs) are developed through the use ofhardware description languages (HDLs). HDLs such as Verilog®, VHDL®, andthe like allow developers to create software-based representations ofcircuit designs. One advantage of using an HDL is the potential for codereuse from one design to another. This concept has been realized withthe commercial availability of intellectual property (IP) cores. Ingeneral, an IP core refers to a software representation of asemiconductor, a circuit design, or any portion thereof, that provides aprocessing function.

IP cores are made available by hardware vendors and other third partysuppliers. Presently, there is a strong demand for IP cores as designersuse these software components to create and simulate embedded designsand digital signal processing designs. IP cores typically areimplemented in an HDL. If distributed in this form, however, allinformation, whether licensed or not, relating to the supplier's IP coreor the circuit design represented by the IP core would be revealed tothird parties. Accordingly, IP core providers have an interest insecuring IP cores prior to distribution and protecting them from reverseengineering.

One technique for securing an IP core is to pre-compile it prior todistribution to third parties. The IP core is distributed as compiledobject code, which effectively encrypts the IP core. This manner ofprotection requires that the IP core be compiled specifically for usewith each different third party simulation tool with which the IP coreis to be used. The IP core is compiled using a third party compilerintended for use with the target simulator. Because the IP core isoriginally coded in a particular type of HDL, such as Verilog® forexample, the resulting compiled object code must be executed in aparticular type of Simulator. For example, simulation of a Verilog® IPcore requires a Verilog® simulator. Alternatively, the user can purchasea mixed language simulator capable of executing both Verilog® and VHDL®IP cores. Mixed language simulators, however, can be very costly for theend user.

Another disadvantage of providing a pre-compiled IP cores is that the IPcore may not be completely secure. Because the IP core is compiled usinga third party compiler, it may be possible for the compiler creator, oranother party, to inadvertently or deliberately reconstitute the objectcode into human readable form. This would expose the IP core provider'ssensitive information.

Even if the IP core is not de-compiled, many third party encryptionmechanisms still leave design details, such as the design hierarchy,exposed when the compiled IP core is used within the simulator. Forexample, when the compiled code of the IP is loaded into an HDLsimulator, details such as the design hierarchy, names of signals,widths of signals, and the like, typically can be viewed. Also, thevalues of internal signals can be traced and/or viewed duringsimulation.

Another technique for securing an IP core is to provide the IP core inencrypted form. In that case, the IP core provider provides aninterface, for example a SWIFT model (a description can be found atwww.synopsys.com/products/ipmodeling/vmc_ds.html), to the encrypted IPcore. This manner of protection, however, is not suited for use withparameterizable IP cores. A parameterizable IP core allows a user tospecify a particular value for an attribute “X” of the IP core, therebyaltering the functionality and/or interface of the IP core in somefashion according to the assigned value of “X”. To produce aparameterizable, encrypted IP core, a different interface would have tobe created for each possible value of “X” for the end user to utilizethe full range of functionality offered by the parameterizable IP core.If the IP core has more than one adjustable attribute, such an interfacewould need to be created for each possible combination of attributevalues, leading to a combinatorially large, and infeasible, number ofinterfaces to be created.

It would be beneficial to provide a technique for creating and usingsecure IP cores in a manner which overcomes the limitations describedabove.

SUMMARY OF THE INVENTION

The present invention provides methods and articles of manufacturerelating to secure software representations of circuit designs. Oneembodiment of the present invention can include a method of creating asecure intellectual property (IP) representation of a circuit design foruse with a software-based simulator. The method can include translatinga hardware description language (HDL) representation of the circuitdesign into an encrypted, intermediate form, which subsequently can bedeleted. The encrypted intermediate form can be an encrypted form of ageneral-purpose, high level programming language, such as C++.

The translating step can include obfuscating the HDL representation ofthe circuit design. The translating step also can include generating awrapper interface. The wrapper interface can implement a standardforeign object interface for the circuit design. The secure IPrepresentation of the circuit design can support, or be used within,both event-driven and cycle-based simulations.

The intermediate form of the circuit design and the wrapper interfacecan be compiled to produce encrypted object code. The encrypted objectcode can be linked with a simulation kernel library thereby creating thesecure IP representation of the circuit design. The linking step caninclude creating an encrypted simulation model of the circuit design anda simulation kernel configured to execute the encrypted simulationmodel. In one embodiment, the secure IP representation of the circuitdesign can be implemented as a shared object library.

An HDL wrapper that specifies an interface for one or more types of HDLfor the secure IP representation of the circuit design also can becreated. The method further can include parameterizing the encryptedsimulation model by passing a value for a parameter of the secure IPrepresentation of the circuit design into the simulation kernel during asimulation session.

Another embodiment of the present invention can include a secure IPrepresentation of a circuit design for use in a third-party simulator.The secure IP representation can include an encrypted simulation objectrepresenting the circuit design and a simulation kernel configured toexecute the encrypted simulation object. The secure IP representationfurther can include an HDL wrapper configured to serve as an interfacebetween the third party simulator and the simulation kernel.

The encrypted simulation object can include a standard foreign objectinterface. The HDL wrapper can specify an interface for a plurality ofhardware description languages. The secure IP representation can beparameterized by passing at least one value for parameterizing thesecure IP representation to the simulation kernel.

Yet another embodiment of the present invention can include a machinereadable storage having stored thereon a plurality of code sections forcausing a machine to perform the various steps and/or functionsdescribed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

There are shown in the drawings, embodiments which are presentlypreferred; it being understood, however, that the invention is notlimited to the precise arrangements and instrumentalities shown.

FIG. 1 is a block diagram illustrating a system for creating a securesoftware representation of a circuit design in accordance with oneembodiment of the present invention.

FIG. 2 is a flow chart illustrating a method of creating and using asecure software representation of a circuit design in accordance withanother embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

While the specification concludes with claims defining the features ofthe invention that are regarded as novel, it is believed that theinvention will be better understood from a consideration of thedescription in conjunction with the drawings. As required, detailedembodiments of the present invention are disclosed herein; however, itis to be understood that the disclosed embodiments are merely exemplaryof the invention, which can be embodied in various forms. Therefore,specific structural and functional details disclosed herein are not tobe interpreted as limiting, but merely as a basis for the claims and asa representative basis for teaching one skilled in the art to variouslyemploy the inventive arrangements in virtually any appropriatelydetailed structure. Further, the terms and phrases used herein are notintended to be limiting but rather to provide an understandabledescription of the invention.

The embodiments described herein relate to software representations ofcircuit designs which can be executed by a software-based simulator. Inaccordance with the embodiments disclosed herein, a securesoftware-based representation of a circuit design, referred to as asecure Intellectual Property (IP) core, or secure IP, can be created.The secure IP provides a high degree of security in that decryptingand/or decoding the secure IP into a human readable format isexceedingly difficult. The secure IP can be executed directly by asoftware-based simulator, whether the simulator is configured as aVerilog simulator, a VHDL simulator, or a mixed-language simulator. Thesecure IP remains parameterizable when used with the simulator despitethe high level of security provided.

FIG. 1 is a block diagram illustrating a system 100 for creating asecure software representation of a circuit design in accordance withone embodiment of the present invention. As shown, system 100 includes amodel compiler 105 and a hardware description language (HDL) simulationkernel library 110. In general, the model compiler 105 processes an HDLrepresentation 115 of a circuit design to create a secure softwarerepresentation of the circuit design, referred to as secure IP 120. TheHDL representation 115 can be an IP core (for example, PCI Express,Ethernet MAC, PowerPC, or other soft cores commercially available fromXilinx, Inc.) or another HDL-based software representation of a circuitdesign that can be loaded and executed by a software-based simulationtool (for example, Mentor graphic's ModelSim simulator). An HDL wrapper125 also is created which, in conjunction with other components of thepresent invention to be described herein, allows the secure IP 120 to beused seamlessly with a variety of different simulators.

As shown, the model compiler 105 includes an HDL parser 130 and a HighLevel Programming Language (HLL) compiler 145. The HDL parser 130processes the HDL representation 115 to produce an intermediaterepresentation 135. The intermediate representation 135 can be atranslation of the HDL representation 115 into a general-purpose HLLrepresentation of the circuit design. In one embodiment, the HLL usedcan be C or C++. It should be appreciated, however, that the particularHLL used is not intended to limit the present invention and that any ofa variety of different general-purpose HLLs can be used. In any case,the HDL parser 130 translates the HDL representation 115 into theintermediate representation 135. Further, the HDL parser 130 can encryptthe resulting intermediate representation 135. Accordingly, theintermediate representation 135 that is provided as output from the HDLparser 130 is an encrypted, general-purpose, HLL representation of thecircuit design. An example of a HDL parser 130 is the Verific HDL parserfrom Verific Design Automation, Inc. which can be used to build adesired HDL to HLL compiler capable of generating a HLL model 135 forthe HDL representation 115. Examples of a HLL compiler are Gnu C/C++compiler and Microsoft C++ compiler.

In one embodiment, the intermediate representation 135 is encrypted in amanner that is specific to the implementation of the HDL simulationkernel library 110. The intermediate representation 135 is valid HLLcode that can be compiled by a compiler without any specialconfiguration. In generating the intermediate representation 135, theHDL parser 130 obfuscates the resulting code by obfuscating symbols thatare defined in the HDL simulation kernel library 110. Obfuscated, orshrouded, code refers to source code that is difficult to read orunderstand. Languages such as C, C++, and Perl, for example, areconsidered obfuscatable languages. The HDL parser can mask the standardlanguage syntax and grammar from the main body of code. In any case, thedefinitions of obfuscated symbols are hidden within the HDL simulationkernel library 110. Any of a variety of different obfuscation techniquescan be used including, but not limited to, layout obfuscation, dataobfuscation, storage obfuscation, encoding obfuscation, aggregationobfuscation, ordering obfuscation, control obfuscation, aggregationobfuscation, or the like.

The HDL parser 130 further generates a wrapper interface 140. Thewrapper interface 140 can be formatted, or implemented, using the samegeneral-purpose HLL into which the HDL representation 115 is translated.The wrapper interface 140 provides a standardized interface to theintermediate representation 135 of the circuit design. Unlike theintermediate representation 135, the wrapper interface 140 is notencoded or translated into an encrypted form.

In one embodiment, the wrapper interface 140 can be described using oneor more of the standard foreign model interfaces used to interface anHDL description of a circuit design with other components coded in C,another HLL, or other third-party software. Examples of standard foreignmodel interfaces can include, but are not limited to, ProgrammingLanguage Interface (PLI) as is used for providing Verilog support,Foreign Language Interface (FLI) as is used for providing VHDL support,and/or VHDL Procedural Interface (VHPI).

The HLL compiler 145 compiles the intermediate representation 135 andthe wrapper interface 140. More particularly, the HLL compiler 145 canbe configured to compile the particular HLL into which the intermediaterepresentation 135 and the wrapper interface 140 are translated and/orimplemented. The HLL compiler 145 compiles the intermediaterepresentation 135 and the wrapper interface 140 into native encryptedobject code 150. As noted, because the intermediate representation 135is valid HLL code, the compiler 145 need not include any specialfunctionality for processing the intermediate representation 135.

The linker 155 links together the various portions of native encryptedobject code that may be created as output from the HLL compiler 145. Asknown, source code, whether HDL or HLL, may be located in more than onefile. In such cases, the HLL compiler 145 may convert the separatesource files into object code that also is in separate files. In orderto create a single executable program or object, the separate objectfiles are combined together using linker 155.

The linker 155 further links, or incorporates, the HDL simulation kernellibrary 110 with the native encrypted object code 155 to produce thesecure IP 120. In one embodiment, the secure IP 120 can be implementedas a shared object library, for example a dynamic link library (DLL). Inany case, the secure IP 120 can include two components, an encryptedsimulation model 165 and a simulation kernel 170 which executes theencrypted simulation model 165. The simulation kernel 170 is createdfrom the various functions of the HDL simulation kernel library 110.

The HDL parser 130 also generates an HDL wrapper 125. The wrapper 125,in combination with the kernel 170, allows a simulator to seamlesslyexecute the secure IP 120 as any other HDL IP core. The wrapper 125 cansensitize the interface signals of the secure IP 120 to the HDLsimulation kernel 170, which is foreign to the third party HDL simulatorwithin which the secure IP 120 is used.

With respect to Verilog, for example, the HDL wrapper 125 can include amodule declaration which describes the interface and functionalcomposition of the secure IP 120 to other designs in the sameenvironment, i.e. simulation. With respect to VHDL, the HDL wrapper 125can include various types of declarations such as an entity-architecturepair which provides the necessary port and functional description of thesecure IP 120. The HDL wrapper 125 can specify the interface of thesecure IP 120 for more than one type of HDL, i.e. both Verilog® andVHDL®, thereby allowing either type of simulator, as well as a mixedlanguage simulator, to effectively execute the secure IP 120.

In illustration, when a value of a signal on the HDL wrapper 125changes, the HDL simulation kernel 170 is invoked and evaluates theencrypted simulation model 165. The HDL simulation kernel 170 passesback the evaluated output through HDL wrapper 125 to the third party HDLsimulator. Depending upon the particular secure IP model, it may berequired at times to register a time based call back on the third partyHDL simulator so that HDL simulation kernel 170 can synchronize eventswith the kernel of the third party HDL simulator.

The HDL simulation kernel 170 does not have a full view of the secure IP120. Details of the secure IP 120 are distributed across compiled,encrypted, simulation model code 165 and the HDL simulation kernel 170.The HDL wrapper 125 also does not allow third parties to gain access toany information regarding the secure IP 120.

The HDL wrapper 125 also can be used by the simulator to load the secureIP 120. While other IP cores execute within the third party HDLsimulator, the encrypted simulation model 165 is executed by thesimulation kernel 170. The simulation kernel 170 functions as acontainer and interface between the encrypted simulation model 165 andthe third party HDL simulator. Further, one or more values for differentparameters of the secure IP 120 can be passed into the encryptedsimulation model 165 via the simulation kernel 170. Because values forparameters do not have to be fixed at the time the secure IP 120 iscreated, the embodiments described herein are well suited for use withparametric IP cores.

Once the secure IP 120 and the HDL wrapper 125 are generated, the HLLcompiler 145 can discard the intermediate representation 135 as well asthe wrapper interface 140 as illustrated by trash bin 160. Thecomponents can be deleted in a secure fashion such that neither isrecoverable. This provides an added measure of security for theresulting secure IP 120.

As noted, once generated, secure IP 120 can be used seamlessly within athird party simulator. To illustrate one way in which the secure IP 120can function, consider the generalized case in which the encryptedsimulation model 165 of secure IP 120 has a port named “CLOCK”. TheCLOCK port is driven by the third party simulator. The third partysimulator can access the functionality of the secure IP 120 via HDLwrapper 125. The simulator drives the CLOCK port by placing a clockchange command on the HDL wrapper 125. The HDL wrapper 125, in turn,invokes a function within the simulation kernel 170 to change the clockof the encrypted simulation model 165. The simulation kernel 170 callsthe appropriate function of the encrypted simulation model 165, orotherwise interacts with the encrypted simulation model 165, to causethe clock to change as requested by the simulator. Values returned fromthe encrypted simulation object 165 are provided to the simulationkernel 170, which in turn provides those values to the HDL wrapper 125to be provided to the simulator.

The wrapper interface 140, which is included in the encrypted simulationobject 165, can arbitrate transactions between the third party simulatorand the secure IP 120. That is, as the wrapper interface 140 implementsan interface which is known to the third party simulator, the wrapperinterface 140 can perform any translations that may be required inpassing communications between the third party simulator and theencrypted simulation object 165. The wrapper interface 140 effectivelyprocesses boundary transactions between the third party simulator andthe Secure IP.

FIG. 2 is a flow chart illustrating a method 200 of creating and using asecure software representation of a circuit design in accordance withanother embodiment of the present invention. Method 200 can be performedby a system such as the one illustrated with reference to FIG. 1.Accordingly, in step 205, an HDL representation of a circuit, such as anIP core, can be loaded into the model compiler. In step 210, the HDLrepresentation can be parsed by an HDL parser in the model compiler toidentify the various elements of the HDL representation.

In step 215, the HDL representation of the circuit design can betranslated into a general-purpose, encrypted, HLL representation of thecircuit design by the HDL parser. In step 220, the HDL parser cangenerate a wrapper interface to the encrypted HLL representation of thecircuit design. The wrapper interface can be described according to oneor more standardized foreign model interface specifications.Accordingly, the simulator with which the secure IP is used need onlysupport one of the foreign model interfaces incorporated into the secureIP.

In step 225, an HLL compiler in the model compiler can compile theencrypted HLL representation of the circuit design along with thewrapper interface. The output from the HLL compiler is native encryptedobject code. In step 230, a linker can link the various portions ofencrypted object code as well as link or incorporate the HDL simulationkernel library. The output from the linker is the secure IP which can beimplemented as a shared object library such as a DLL as noted.

In step 235, the encrypted HLL representation of the circuit design,i.e. referred to as the intermediate representation, as well as theinterfaces that were generated can be deleted. In step 240, an HDLwrapper can be generated that specifies the design hierarchy of thesecure IP. Once generated, the secure IP can be used with a simulator instep 245 using the HDL wrapper as any other IP core. As noted, theencrypted simulation model can be executed by the simulation kernel.With this structure, the secure IP can be executed in a simulator thatdoes not support the original type of HDL used to create the softwarerepresentation of the circuit design. For example, if the original HDLrepresentation was coded in Verilog®, the resulting secure IP can beused seamlessly within a simulator configured to execute VHDL®.

The embodiments disclosed herein provide a solution for creating asecure software representation of a circuit design. The encryptedsimulation model incorporates standardized foreign model interfaces andan HDL wrapper which facilitates use of the encrypted model by a varietyof different simulators including Verilog®, VHDL®, and mixed language.Since the encrypted model is executed using its own simulation kernel,the secure IP described herein is useful for parametric models as valuesneed not be fixed at the time the secure IP is created, but rather canbe passed to the IP during simulation. It also should be appreciatedthat due to the inclusion of the self-contained simulation kernel, thesecure IP can support both event-driven and cycle-based simulationtechniques. That is, the resulting secure IP can be used within acycle-based simulation and within a transaction-based simulation sincecontrol over the encrypted object model is exercised via the simulationkernel included therein. Combining both varieties of simulation cansignificantly increase the speed of simulation.

The embodiments disclosed herein can be realized in hardware, software,or a combination of hardware and software. The embodiments can berealized in a centralized fashion in one computer system or in adistributed fashion where different elements are spread across severalinterconnected computer systems. Any kind of computer system or otherapparatus adapted for carrying out the methods described herein issuited. A typical combination of hardware and software can be ageneral-purpose computer system with a computer program that, when beingloaded and executed, controls the computer system such that it carriesout the methods described herein. The embodiments described herein alsocan be embedded in a computer program product, which comprises all thefeatures enabling the implementation of the methods described herein,and which when loaded in a computer system is able to carry out thesemethods.

The terms “computer program”, “software”, “application”, variants and/orcombinations thereof, in the present context, mean any expression, inany language, code or notation, of a set of instructions intended tocause a system having an information processing capability to perform aparticular function either directly or after either or both of thefollowing: a) conversion to another language, code or notation; b)reproduction in a different material form. For example, a computerprogram can include, but is not limited to, a subroutine, a function, aprocedure, an object method, an object implementation, an executableapplication, an applet, a servlet, a source code, an object code, ashared library/dynamic load library and/or other sequence ofinstructions designed for execution on a computer system.

The terms “a” and “an”, as used herein, are defined as one or more thanone. The term “plurality”, as used herein, is defined as two or morethan two. The term “another”, as used herein, is defined as at least asecond or more. The terms “including” and/or “having”, as used herein,are defined as comprising (i.e., open language).

This invention can be embodied in other forms without departing from thespirit or essential attributes thereof. Accordingly, reference should bemade to the following claims, rather than to the foregoingspecification, as indicating the scope of the invention.

1. A method of creating a secure intellectual property (IP)representation of a circuit design for use with a software-basedsimulator, said method comprising: translating a hardware descriptionlanguage representation of the circuit design into an intermediate formspecified using a general-purpose, high level programming language;obfuscating the general-purpose, high level programming language of theintermediate form using at least one obfuscation technique operable onthe general-purpose high level programming language; compiling theintermediate form of the circuit design to produce encrypted objectcode; and linking the encrypted object code with a simulation kernellibrary creating the secure IP representation of the circuit designcomprising an encrypted simulation model of the circuit design and asimulation kernel configured to execute the encrypted simulation modelin coordination with the simulator, wherein the simulator is a hardwaredescription language simulator.
 2. The method of claim 1, saidtranslating step further comprising generating a wrapper interface,wherein the wrapper interface implements a standard foreign objectinterface for the circuit design.
 3. The method of claim 2, wherein thesecure IP representation of the circuit design supports event-driven andcycle-based simulation.
 4. The method of claim 1, wherein the secure IPrepresentation of the circuit design is implemented as a shared objectlibrary.
 5. The method of claim 1, further comprising parameterizing theencrypted simulation model by passing a value for a parameter of thesecure IP representation into the simulation kernel during a simulationsession.
 6. The method of claim 1, said translating step furthercomprising obfuscating the hardware description language representationof the circuit design.
 7. The method of claim 1, further comprisingcreating a hardware description language wrapper specifying an interfacefor at least one type of hardware description language for the secure IPrepresentation.
 8. The method of claim 1, wherein the intermediate formof the circuit design comprises an encrypted form of thegeneral-purpose, high level programming language.
 9. The method of claim1, further comprising deleting the intermediate form of the circuitdesign.
 10. A computer configured to execute a secure IntellectualProperty (IP) representation of a circuit design for use with a hardwaredescription language simulator, the computer comprising: an encryptedsimulation object representing the circuit design compiled from anobfuscated, general-purpose, high level programming languagerepresentation of the circuit design; a simulation kernel configured toexecute the encrypted simulation object in coordination with thehardware description language simulator; and a hardware descriptionlanguage wrapper configured to serve as an interface between thehardware description language simulator and the simulation kernel. 11.The computer of claim 10, wherein the encrypted simulation objectcomprises a standard foreign object interface.
 12. The computer of claim10, wherein the hardware description language wrapper specifies aninterface for a plurality of hardware description languages.
 13. Thecomputer of claim 10, wherein the secure IP representation isparameterized by passing at least one value for parameterizing thesecure IP representation to the simulation kernel.
 14. A machinereadable storage having stored thereon a computer program having aplurality of code sections comprising: code for translating a hardwaredescription language representation of a circuit design into anintermediate form, wherein the intermediate form is an encrypted,general-purpose, high level programming language representation of thecircuit design; code for obfuscating the general-purpose, high levelprogramming language of the intermediate form using at least oneobfuscation technique operable on the general-purpose high levelprogramming language creating the encrypted, general-purpose, high levelprogramming language representation of the circuit design; code forcompiling the intermediate form of the circuit design to produceencrypted object code; and code for linking the encrypted object codewith a simulation kernel library thereby creating the secure softwareobject representation of the circuit design comprising an encryptedsimulation model and a simulation kernel configured to execute theencrypted simulation model in cooperation with the software-basedsimulation system, wherein the simulation system comprises a hardwaredescription language simulation system.
 15. The machine readable storageof claim 14, further comprising code for generating a wrapper interfacethat implements a standard foreign object interface for the circuitdesign.
 16. The machine readable storage of claim 15, wherein the secureIP representation of the circuit design supports event-driven andcycle-based simulation.
 17. The machine readable storage of claim 14,wherein the secure software object representation is parameterized bypassing a value of a parameter to the encrypted simulation model via thesimulation kernel.
 18. The machine readable storage of claim 14, furthercomprising code for creating a hardware description language wrapperspecifying an interface for the secure software object representationusing at least one hardware description language.
 19. The machinereadable storage of claim 14, further comprising code for deleting theencrypted intermediate form of the circuit design.